Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000117_owner-urn-ietf _Fri Oct 25 17:36:49 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA02666 for urn-ietf-out; Fri, 25 Oct 1996 17:36:49 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA02654 for <[e-mail]>; Fri, 25 Oct 1996 17:36:45 -0400
Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA09356  (mail destined for [e-mail]); Fri, 25 Oct 96 17:36:35 -0400
Received: from ishtar.fsc.fujitsu.com (ishtar.fsc.fujitsu.com [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id OAA14553; Fri, 25 Oct 1996 14:34:35 -0700 (PDT)
Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id OAA07165; Fri, 25 Oct 1996 14:34:58 -0700 (PDT)
Date: Fri, 25 Oct 1996 14:34:58 -0700 (PDT)
From: Terry Allen <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: [URN] URN Syntax thoughts
Sender: [e-mail]
Precedence: bulk
Reply-To: Terry Allen <[e-mail]>
Errors-To: [e-mail]
Ron:

| >I'm not seeing any closure on the UTF-8 issue,
|
| I'm willing to give this issue some more time. I have not seen any

as am I.

| strong opposition to using UTF-8. What I think is the outstanding
| question on the use of UTF-8 is something like "what about namespaces
| that want to provide octets that are not UTF-8?"
|
| My answer: Tough. If people want to ship around binary data as their
| names, then they can encode it in a fashion similar to the data:
| URL scheme where they have 2 choices:
|   1) Base64  (which uses only safe characters)
|   2) %encoding (which uses only safe characters)

Suppose they don't, though?  What is the effect of saying "tough"?
What happens to people who contumaciously people promulgate URNs that
(perhaps only in part) are not encoded in UTF-8 (and, perhaps, are not
even in Unicode).  Or who do this because their software is buggy
or because their employers made them do it (think Dilbert)?
What will break?

The intuition of Joe Namespace is likely to be that he can construct
a URN for his unique name (XXXXXX, not in UTF-8) by prefixing those
hierarchical name space division markers he usually takes for
granted (A/B/C/XXXXXX), prefixing the NIS for his top-level
name space (sludge:A/B/C/XXXXXX), and depending on his religion
(though we really should not use the term "religious issue" in
a formal document ...), prefixing "urn:".  Leaving aside the
question of whether A/B/C is in UTF-8, is it plausible to believe
that Joe Namespace will accept a regime in which his unique name
is XXXXXX but appears in a URN as XYZXYZ (UTF-8 encoded)?

I'm inclined to think that urn:sludge:A/B/C/XXXXXX should be
allowed because it seems like common sense (to me, at the moment,
still), and will occur (because it seems like common sense to
Joe Namespace, or his employer, or because Joe lacks a tool that does
UTF-8 conversion).

What arguments are there that urn:sludge:A/B/C/XXXXXX cannot be
resolved if urn:sludge:A/B/C/XYZXYZ can be?  (as distinct from
arguments that XYZXYZ can be resolved faster or more efficiently
than XXXXXX.)  And what of the two subcases:  A/B/C/ is UTF-8
or is not?


Regards,
    Terry Allen    Fujitsu Software Corp.    [e-mail]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html